test(selfupdate): pin the archive path guards, reject zero-length binaries, add fuzzing - #64

Parts 2–3 of 8. Base: test/isolation-harness (#63) — that must merge first.

Defensive security work on our own updater. Hostile archive fixtures are built in-memory; nothing is written to disk or followed.

The headline defect

A tar.TypeSymlink entry named grant with Size: 0 made extractBinary return (empty, nil). applyBinary hashes whatever it is handed, so an empty payload verifies against itself and installs — bricking the user's binary. Reproduced twice independently as bytes=0 err=<nil>.

Zero-length binaries are now rejected in both extractors and at applyBinaryTo.

Also fixed

• Six path guards had no real coverage. The malicious fixtures contained only the malicious entry, so extraction failed with "does not contain a grant binary" regardless of which guard fired — and the table asserted only that an error occurred. Each now has a valid grant beside it plus a guard-specific wantErrContains.
• The UNC guard was dead code. path.Clean("//host/share/x") collapses to /host/share/x, so path.IsAbs always won. Reordered. Verified message-only: 35 hand-picked inputs plus every string of length ≤5 over {/ \ . : C c 1 a} — 37,449 strings, zero decision differences.
• zip had no non-regular guard. A fs.ModeSymlink entry named grant.exe was accepted in production, unmutated. Now f.Mode()&fs.ModeType != 0, mirroring tar.
• Fuzz targets for checkArchivePath and both extractors, seeded with the hostile cases.

Non-regular entries: pinned behaviorally, not by wording

An earlier revision of this PR claimed each non-regular case had "a valid grant beside it plus a guard-specific wantErrContains". That was false, and a review caught it: all seven cases asserted the generic fallback "does not contain a grant binary", and none placed a valid binary beside the hostile entry. Neutering isBinaryEntry to return false left the entire table passing, so the test could not distinguish the type guard skipping the entry from isBinaryEntry failing to match from checkArchivePath rejecting it.

TestExtractBinaryRejectsNonRegularEntries is now inverted into a success assertion. Two entries cannot both be named grant, but isBinaryEntry accepts grant and grant.exe in either archive format, so each hostile entry is paired with a valid binary under the other name — valid binary first, so the zero-length backstop cannot fire before the duplicate is seen:

archive: buildHostileTarGz(t, []tarEntry{
    {name: "grant.exe", body: fixtureBinaryContents},
    {name: "grant", typeflag: tar.TypeSymlink, linkname: hostileSymlinkTarget},
}),
// assert: err == nil && string(got) == fixtureBinaryContents

Mutation evidence (all previously survived or died only on wording):

The rejection half of the class is kept as TestExtractBinaryRejectsNonRegularOnlyArchive, explicitly documented as wording-shaped and carrying no mutation-killing weight of its own.

FuzzCheckArchivePath's oracle was not independent

The property body re-implemented checkArchivePath's switch verbatim — including calling the production hasDriveLetter — so a defect inside that helper was invisible to the fuzzer. Narrowing hasDriveLetter to uppercase-only drives survived 2,450,979 execs in 30s, while TestCheckArchivePath/lowercase_drive caught it instantly.

The oracle now uses its own inlined drive-letter predicate. The same mutation is killed on seed corpus entry #9 in 0.12s: accepted a drive-absolute path: "c:\\grant.exe". The comment claiming the target "asserts the guard's CONTRACT" was also overstated and now says what is true: it checks a necessary condition on accepted names, and an over-eager guard that rejects legitimate names passes it trivially — TestCheckArchivePath owns that side.

Notes a reviewer should not skip

• Go's tar.Reader forces nb=0 for header-only types (symlink, hardlink, dir, char, block, fifo). TypeCont and vendor types 'A'..'Z' are not header-only and carry readable bytes — with the type guard removed they would extract attacker-chosen bytes and the zero-length backstop would never fire. This is why the type guard must never be removed in favour of that backstop.
• The tar/zip decompression-bomb asymmetry is intentional, not a bug: zip.NewReader parses only the central directory and never inflates skipped entries. Measured — a 1000:1 bomb inflated nothing in 126 µs. Pinned with a passing test.
• Neither size cap is an aggregate cap. hdr.Size > maxDownloadBytes bounds each entry and readCapped bounds the binary, but nothing bounds total inflated bytes or entry count, and tar.Reader.Next() must inflate every skipped entry to reach the next header. Measured: an 8.3 MB archive walks 65 entries in 2.45s; extrapolated to the 128 MiB cap that is ~40s CPU and ~128 GiB inflated. No code change — verifyChecksum runs before extractBinary, so an attacker must already control checksums.txt, which the documented trust model already excludes. Recorded in the test comment and in CLAUDE.md.
• FuzzExtractFromZip previously wedged to 0 exec/sec and still printed PASS. Diagnosed as throughput collapse on near-cap inputs (128 MiB io.ReadAll per exec), not a production hang. Fixed by capping maxDownloadBytes inside the targets; it now sustains the highest throughput of the three (2.95M execs / 30s).
• Won't-fix, recorded: the len(data) != hdr.Size cross-checks are unreachable — a successful capped read returns exactly hdr.Size, and earlier exhaustion returns io.ErrUnexpectedEOF. Kept as defense-in-depth, claiming no coverage.
• Known gap: the failing-fsync test uses a FIFO and is //go:build !windows. No portable Windows equivalent exists — FlushFileBuffers succeeds on both named pipes and regular files.
• CLAUDE.md was pruned back. An earlier revision added ~8 PR-length paragraphs of test-file structure, fuzz exec-rate diagnostics and mutation-survival rationale to the grant update bullets. Per the repo's own convention that material belongs here, not there; CLAUDE.md now keeps only the UNC ordering, the symmetric type guards, the intentional size-check asymmetry plus the aggregate-cap sentence, and the existence of the fuzz targets.

17/17 mutations killed. Adversarial review performed (Codex credits exhausted; review by a Claude agent). All findings fixed, including the two above, which were found in a second adversarial pass against this PR's own claims.